\section{Entwurfsentscheidungen}

%Zentrale, prägende und wichtige Entscheidungen.

\begin{itemize}
	\item Die Rollen \emph{Autor}, \emph{Redner} und \emph{Teilnehmer} sind zusammengefasst als Teilnehmer. Der Hintergrund ist, dass ein Autor und ein Redner als eine Person betrachtet werden kann. Dieser kann jedoch auch gleichzeitig ein Teilnehmer sein, weshalb eine Unterscheidung dieser drei Rollen als nicht sinnvoll erscheint.
	
	\item Jede View besteht aus einem JSP (\emph{*.jsp}-Datei sowie etwaige CSS oder JavaScript Funktionen) und einem dazu passenden Java-Servlet. Obwohl möglich, ist nicht gewollt, dass ein Servlet die Controller-Logik für alle Views übernimmt, da dies schnell zu einem \emph{Big-Hairy-Object} oder zu einem \emph{God-Object} führen könnte.
	
	\item Jede einzelne View benötigt in seinem Servlet verscheidene Funktionalitäten im Backend, welche als Stateless Beans realisiert sind. Die Entwicklung war folgendermaßen:
		\begin{enumerate}
			\item Jede einzelne Funktionalität wurde als eigene Bean realisiert. Die Folge waren viele kleine Objekte und viel Boilerplate-Code, wie Klassendefinitionen und -namen sowie entsprechende Schnittstellen. Die Größe war jedoch aufgrund fehlender Daten, diese stecken in den Entitäten, irrelevant.
			\item Die zweite Version sah vor, dass alle Funktionalitäten, die von einem Servlet gebraucht werden auch in eine Bean zusammengefasst werden. Die Anzahl der Beans verringerte sich so auf die Anzahl der vorhandenen Views. Ein Nachteil ist die logische Verknüpfung von Funktionalität an die View-Komponenten.
			\item Die aktuelle Version fasst alle Funktionalitäten in eine Bean zusammen, die mit einer Entity zusammenhängen. Pro Entity existiert nun eine Bean mitsamt lokalem Interface. Der Grund hierfür ist der stärkere logische und semantische Zusammenhang als bei der zweiten Version.
		\end{enumerate}
\end{itemize}
